home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.20021006-20030409
/
000320_b.stewart@bom.gov.au_Mon Feb 17 19:39:35 EST 2003.msg
< prev
next >
Wrap
Text File
|
2020-01-01
|
6KB
|
140 lines
Article: 14116 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!phl-feed.news.verio.net!iad-feed.news.verio.net!ord-feed.news.verio.net!stl-feed.news.verio.net!newsreader.wustl.edu!gumby.it.wmich.edu!out.nntp.be!propagator2-SanJose!in.nntp.be!newsfeed01.tsnz.net!ken-transit.news.telstra.net!news.telstra.net!vicpull1.telstra.net!not-for-mail
Message-ID: <3E517F57.4394B12E@bom.gov.au>
From: Bruce Stewart <b.stewart@bom.gov.au>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Running multiple kermit scripts on one connection
References: <775a2ab0.0302171458.f8f21f9@posting.google.com> <b2rrbl$ks3$1@watsol.cc.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 118
Date: Tue, 18 Feb 2003 11:33:27 +1100
NNTP-Posting-Host: 134.178.5.131
X-Complaints-To: abuse@telstra.net
X-Trace: vicpull1.telstra.net 1045528188 134.178.5.131 (Tue, 18 Feb 2003 11:29:48 EST)
NNTP-Posting-Date: Tue, 18 Feb 2003 11:29:48 EST
Organization: Customer of Telstra Internet Direct
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:14116
By the way, I'm using another account from now on. Its from a
friend of mine named Bruce Stewart. So you will see Bruce Stewart
in the Sender field, but it is really me, Minty.
Frank da Cruz wrote:
> In article <775a2ab0.0302171458.f8f21f9@posting.google.com>,
> Minty <metceed@yahoo.com> wrote:
> : I'm trying to run multiple kermit scripts over one dial-up connection.
> : More specifically:
> :
> : I am writing a program that will automatically send an alert. One the
> : the ways it sends an alert is via an sms message. I have an account
> : with an pstn-to-sms gateway provider. So I can dial-up this gateway
> : modem, and using the TAP protocol, I can send sms messages.
> :
> : What I want to do is control, within my program, the 2 main aspects of
> : the sending process. The 'loggin on' part, and the 'sending messages
> : part'. I already have a kermit script that does both. I want to
> : seperate those to parts and call them seperately from my program. The
> : reason is that there could be many messages going out for the one
> : connection. This is decided at run-time. Another reason is so that the
> : program can know which alerts got sent and which didn't.
> :
> : So, if for example I'm sending out 2 alerts, the steps would be as
> : follows:
> :
> : 1-The program would run a kermit script, that opens connection from
> : local pc to local modem, dials the gateway modem and logs on, as per
> : the TAP protocol. The script would be called with the gateway provider
> : number as parameter.
> :
> : 2-Then the program would run another kermit script, that sends
> : messages as per TAP protocol, with the message and sms number as
> : parameters, noting the exit code.
> :
> : 3-It would again call the same send script with another message and
> : another number as parameter, again noting the exit code.
> :
> : 4-It calls another scipt, that logs off the connection to the gateway
> : modem, and also closes connection from local pc to local modem.
> :
> : Now, the problem I have noted with running multiple kermit scripts, is
> : that at the end of running one script, it closes the connection to the
> : gateway modem and also the connection from the local pc to the local
> : modem.
> :
> : I'm using the latest kermit 95 version on a Windows 2000 machine.
> :
> : Anyone have any ideas on how I could do this? I'm sure it's only a
> : setting I would have to set with kermit, but I haven't found it.
> :
> : One idea I did try was to manually open an instance of kermit and open
> : connection to local modem manually. Then call the other scripts to use
> : this connection, but they wouldn't use it.
> :
> Ideally you'd like to be able to start Kermit and then send it messages
> when you want it to do something. Unfortunately, Kermit doesn't have a
> way to wait for or send messages, so we have to devise a cunning plan.
>
> One idea would be to turn your application upside down and let Kermit
> control the sequence of events. For example, it could make the call, log
> in, and then run your application with a command-line argument that says
> "OK I'm logged in, now what?" and waits for your application to terminate.
> At this point it can dispatch based on the return code, perhaps looking in
> a prearranged file for instructions. Repeat as needed.
>
> If that's not practical, there is a little-known way of making Kermit wait
> for an event:
>
> WAIT <interval-or-clock-time> FILE CREATION <filename>
>
> ("help wait" for details.) This is admittedly a hack, and it would
> require the same thing in the other direction, because at this point
> Kermit is still running.
>
> Thus your application would have to spawn Kermit asynchronously, then
> wait for a prearranged file to appear, which Kermit would create just
> before doing the WAIT. Then your application would do whatever it does,
> and then when it's ready for Kermit to send a message, it would create
> another prearranged file, the one that Kermit is WAITing for. Obviously,
> it would be handy if this file contained the message details.
>
> So the Kermit script would go about like this:
>
> Make the call and log in.
> If this failed, return a failure code.
> If it succeeds, create the "I'm logged in" file.
> While true {
> Wait for message file.
> If message file says "Finished" {
> delete the "I'm logged in" file
> Hang up and exit.
> } else {
> send the message.
> delete (or rename) the message file
> }
> }
>
> Meanwhile your application would:
>
> Spawn Kermit asynchronously
> Wait for the "I'm logged in" file
> While true {
> Make sure "I'm logged in" file still exists.
> Get a message to send.
> Create message file.
> Wait for message file to disappear.
> }
>
> Does this help? It's not the fashiable TLA du jour but we've never been
> particularly concerned with fashion :-)
>
> Obviously refinements are possible, such as queueing and various forms of
> bulletproofing.
>
> - Frank